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ABSTRACT 


Current operations planning and analysis practices on Ni^A/MSFC 
Phase B projects were investigated with the objectives of (1) 
formalizing these practices into a handbook and (2) suggesting 
improvements. The study focused on how Science and Engineering 
(S&E) Operational Personnel Support Program Development (PD) 
Task Tecuns. The intimate relationship between systems 
engineering and operations amalysis was examined. Methods 
identified for use by operations analysts during Phase B 
include functional analysis, interface analysis, data flow . 
diagrams, mission timelines, and specialty analysis methods to 
calculate/allocate such criteria as reliability, 
maintainability, and operations and support cost. 


Conclusions are that at NASA/MSFC, S&E operational activities 
during Phase B may be characterized by: 


1) Phase B operations planning and analysis based on 
experienced judgment. 

2) Operations and servicing concepts and criteria not 
sufficiently developed/ represented on task teams, although 
contractor efforts in these areas are adequate. 

3) EL12 has limited formal methods/data bases /procedures 
in-house to cross check contractor claims, estimates, and 
decisions. 


Recommendations are to: 

1) Develop operations analysis data bases, methods, and 
specialists to adequately staff each Phase B task team. 

2) Give operations and maintenance personnel an equal level of 
authority to system engineering on these teams. 

3) Conduct formal operational studies prior to or early in 
Phase B in order to define operational and maintenance 
concepts prior to system configuration studies. 

4) Assure operational effectiveness criteria and personnel are 
integrated into each Phase B task team. 

5) Upon receipt of Phase B reports, use formal and 
structured in-house methods to validate contractor 
f indings . 
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INTRODUCTION 


Major system acquisitions by NASA are conducted under the 
guidance provided in NASA Management Instruction 7100. 14A, 

NASA's implementation of the guidance specified in the well-known 

0MB Circular • auc ueiin c-iiasc iJ t wi. - ww 

step in the system acquisition process following Mission Need 
Determination and preceding Full-Scale Development (see Figure 
1). Phase B studies may be done in-house, in parallel with one 
or more contractors, or by contractors only. The purpose of 
Phase B studies are to establish technical feasibility, to 
estimate costs and schedules, and to establish confidence that 
a design concept has progressed far enough into preliminary 
design that NASA can commit to full-scale development. Thus, 
Phase B is the critical transition from task team to project 
office. 80-90% of the critical parameters (life-cycle cost, 
mission reliability, etc.) are determined during Phase B, 
although only 10-20% of the engineering effort will have been 
expended. It is therefore absolutely necessary that mission 
operations euid operations effectiveness criteria be adequately 
considered during Phase B. 


Prior to Phase B, the mission development process is highly 
unstructured auid documentation is generally uncontrolled, i.e. 
mission documentation consists of a set of memos, operational 
concept papers, and NASA center position papers. The only 
form a l document is the required Mission Need Statement which 
includes the following operations oriented sections: 


b. Mission Purpose 

c. Existing Capaibility 

f. Value or Worth of Meeting Need 
h. Operating Constraints 


Engineers in EL12, Operations Planning and Analysis, who are 
assigned to participate in a Phase B Task Team therefore are 
generally asked to either produce planning documents and/or 
evaluate contractor studies under the following limitations: 


• little program-specific operational data. 

• limited historical data, unless the current system is 
similar to a previously developed system. 

• no formal methodology to perform their role, i.e. no 
standard methods to perform the functions of planning, 
structuring, analyzing, and deciding. 

Further complications for the operations-oriented engineer in 

Phase B are due to the nature of space activities and the way 

NASA operates as an agency; 

• mission operations are 5-10 years in the future. 

• segments and elements of a mission are widely dispersed 
geographically . 
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• responsibilities for mission and system development divided 
among NASA centers, various contractors, and various users 
(e.g., scientists, faculty, military). 

At Marshall Space Flight Center (MSFC) , mission operations 
responsibility has changed hands a number of times in the past 
twenty- five years. At one time, there was a program office 
called Mission Operations which handled all activities 
including data manageiftent. During the 1970s the program office 
was abolished and all mission operations was moved to the 
Science and Engineering Laboratory but with responsibility 
divided. Data management went to a Data Management Division 
and the remainder went to Systems Analysis & Integration 
Laboratory (SA&IL). After a few years, the data management and 
mission operations fvinctions are together again but at a lower 
level, that is, the Operations Division. 

The role of MSFC mission operations has also changed. In the 
early days, the missions were few and the center was in a 
support role to Johnson Space Center (JSC). Since 1980 the 
center has had a more active mission operations role beginning 
with the Spacelab. The center now has the capability to 
control science and experiment missions from Huntsville. 

The key principles which should guide the development of an 
Operations Planning and Analysis Handbook are these: 

1. Any system NASA procures and eventually flies has a dual 
nature, technical (hardware and software) and social 
(humans — their organizations, responsibilities, roles, and 
role relationships). Thus, system design and operational 
design must occur simultaneously. 

2. Baselines must be established early in Phase B and 

controlled/expanded through later phases. There are at 
least three types of baselines: program, system, 

operations. For systems to be maintained on-orbit, the 
support concept of Phase B becomes part of a logistics 
baseline. 

3. Requirements flow from top-level mission needs/objectives. 
Both technical and operational requirements are derived by 
a continuing iteration between operations analysis and 
system design (Figure 2) at each level of the system 
hierarchy. 

4. Each requirement should be traceable back to its source, 
with access to supporting analyses, policy decisions, 
reasoning, etc. 

5. Each operational requirement should be documented: how 

derived, how allocated, how to be verified. 
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6. In design decisions, operational effectiveness criteria are 
of equal significance with programmatic criteria( 
acquisition cost, schedule and risk) and system performance 
criteria (weights, data rates, pointing error, etc.). 
Operations effectiveness criteria include; 

• reliability 

• maintaineibility 

• safety 

• quality ,inspectability, producibility 

• supportability (if applicable) 

• contamination control 

• manability, repairability 

• operations and support (O&S) cost 

7. Appropriate emphasis on operational effectiveness during 

Phase B can save NASA money and improve programs stability 

by: 


• reducing design changes 

• reducing training complexity 

• reducing risk of cost/ schedule overruns 
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OBJECTIVES 


The objectives of the study reported here were to: 

1. Determine the nature of mission operations analysis 
performed by NASA/MSFC during Phase B studies: 

■ i- — f 

a. HiXUdlU UJ. 

b. Output of studies 

c . Methodology . ^ . 

d. Interaction with systems engineering organizations in 
SA&IL and on PD task teams/project offices. 

e. Interaction with program planning, especially the 
development of operational schedules and O&S cost 
estimates. 

2. Identify ways to improve communications of and emphasis of 
operational concepts and criteria during Phase B: 

a. In-house, among various MSEC organizations and people 

b. Among NASA centers 

c. To and from NASA contractors. 

3. Identify opportunities to use formal scientific methods to 
increase the rigor of : 


a. 

b. 

w m 

d. 


interface definition, analysis, and control 
allocation of functions and responsibilities to 
elements of the social system 
vocninhion of conflicting objectives 
quantifying the probability that mission objectives 


will be met. 
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RKT-ATTOM OF OPERATIONS TO SYSTEM DESIGN 


Large technical organizations such as NASA, according to 
sociotechnical systems theory, are best xonderstood as a complex 
interaction of technical and social factors engaged in 
transforming inputs to achieve desired outputs. More 
precisely, the technical system consists of the means (i.e., 
hardware, software, procedures) by which the people tranform 
the inputs. The social system is the adaptive, mediating 
device between the limits and capacities of the technical 
system and the requirements of environment. The technical 
system is only adaptive in a limited range, and redesign is 
required to perform unanticipated functions or functions in 
different orders or environments than planned. The response 
modes and means for adaptation of the social system must also 
be designed — not established on an ad hoc basis and not as a 
fall-out of technical system design. 

OPERATIONAL DOCUMENTATION INITIATES DESIGN PROCESS 


Operations documentation at a specific phase of a NASA project 
specifies what the organization knows about ends-means 
relationships in the system and adaptive processes to be used 
to control the system. The first half of Phase B is often 
called conceptual design (or feasibility analysis). The 
product of conceptual design is called a technical baseline and 
typically consists of : 

1. A System Operational Concept 

2. A System Maintenance Concept 

3. A Preferred System Configuration 

a. Functional Configuration (Set of functional block 
diagrams ) 

b. Preliminary sizing/ physical characteristics 

A common problem in systems engineering is that system 
configuration studies are initiated prior to definition of 
operational and maintenance concepts, receive much more 
manpower and management attention, and fail to properly 
consider operational /maintenance criteria in decision-making. 
Two ways NASA can avoid this dominance by the configuration 
studies are to either: 

1. Provide Phase B contractors with a good Preliminary System 
Operational Concept (PSOC) document at the beginning, or 

2. Require contractors to fully develop operational and 
maintenance concepts in parallel to, or slightly ahead of, 
configuration studies. 

There is no standard format for a PSOC, although there are 
generally accepted rules for what make up an operational 
concept, a maintenance concept, amd an organizational concept 
during conceptual design. We discuss the contents of these 
three concepts briefly. 
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An operational concept defines how the system will be deployed 
and used, and should include; 


1. Mission definition — prime operating mission of the system 
along with alternative or secondary missions, defined 
through one or a set of scenarios or operational profiles. 


2. Ferfotiuance and physical parameters--definltlon of the 
operating characteristics and fvinctions of the system in 
broad terms. 


3. Operational deployment and geographic 
distribution — identification of quantities /sizes of 
facilities, equipment, personnel along with transportation, 
mobility, and communication requirements. 

4. Operational life cycle — anticipated system life, total 
inventory profile, assignment of units to bases, etc. 


5. Utilization requirements — utilization rates, on-off 
sequences, cycles per year, etc. 

6. Effectiveness factors — system requirements specified in 
terms of operational effectiveness factors such as mean 
time between (MTBF) , maintenance man-hours per operational 
hour (MMH/OH), operator skill levels, safety, and so on. 


7. Environment profile — fur mission as well 
handling, assembly, storage modes. 


trsinspoiftcition - 


The maintpnance concept defines how the system will be 
supported throughout its life-cycle. It delineates: 


1. The levels of maintenance support envisioned (e.g., most 
USAF systems use three levels: operational, intermediate, 
and depot) . 

2. Repair policies — which items will be replaceable, which 
items will be replaced regularly and which only upon 
failure; which removed items will be repaired and which 
discarded; who will be responsible for each maintenance 
activity. The repair policies at Phase B are by no means 
fixed, but must be assumed in order to proceed with design; 
they are amended later. 

3. Maintenance environments, e.g. weightlessness, temperature, 
lighting, etc. 

4. Maintenance effectiveness measures including maintenance 
costs, maintenance skill levels, test equipment reliability 
and quantities, supply responsiveness, etc. 
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The maintenance concept serves two important purposes: 

1. It is the baseline for the establishment of supportability 
requirements and features in the configuration design 
activity. 

2. It is the starting place for establishing the logistics 
support requirements for the system. The maintenance 
concept, supplemented by logistics support analysis, leads 
to identification of the maintenance tasks, skill levels, 
equipment, supply support, facilities, and data. 

Early NASA operational documents (often called a preliminary 
mission operations plan) tend to be heavily oriented toward the 
organizational concept for procuring, testing, and operating 
the system. Organization structure, responsibilities, and 
interfaces are specified. Some discussion of manning, e.g. 
contractor vs civil servant, is provided along with 
communication and control process top-level descriptions. 

These organizational details are certainly necessary for both 
NASA and the contractor, but should not be considered as 
sufficient input of NASA operational personnel to Phase B 
studies . 

The term System Concept is usually synonymous with the 
“preferred system configuration" we listed as the third output 
of conceptual design. One other concept type important to NASA 
is that of an E nd-User Concept which defines, in preliminary 
terms, how the end-user of the system will use the productive 
output of the system. For example, the Science Operation 
Concept for AXAF, or the Military Operations Concept for a 
military force delivered to the front-line by a C-130 aircraft. 

OPERATIONAL CRITERIA INFLUENCE DESIGN DECISIONS 


As shown in Figure 3, operational criteria must be considered 
in design decision-making. Other types of criteria are 
programmatic (acquisition cost, schedule, and risk) and 
performance (range, speed, timing, pointing error, data 
transfer or error rates, etc.), neither of which adequately 
address operational effectiveness — how well will the system, 
segment, element perform its fui:ction during a mission. Among 
the operational criteria that may be appropriate for a given 
design decision are: 

• reliatbility , maintainability, availability 

• safety 

• inspectability , producibility 

• supportability 

• operations and support (O&S) cost 

• habit6d)ility (long-term human occupation) ,maricibility 

• contamination and corrosion control 
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FLOW DIAGRAM FOR PHASE B PLANNING AND REQUIREMENTS DOCUMENTS 
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It is significant to note that all of the above criteria 
reflect either man-machine interfaces or machine-environment 
interfaces. Trade-offs at the man-machine interface 
occasionally drive design in those cases where mission-critical 
timing or safety are potentially threatened. It is also 
important to note that design decisions not only involve 
trade-offs among operational criteria, but also across criteria 
types. Classic examples would be trading O&S cost for 
acquisition cost, or performance for reliability or safety. 

OPERATIONAL PLANS ARE GROUND RULES FOR DESIGN 

Phase B design studies take a proposed system from conceptual 
design to roughly half-way through preliminary design. Design 
is based on assumptions, constraints, and requirements which 
are documented in a group of formal planning and requirements 
documents. The documents produced by systems engineering are 
hardware/ software oriented and typically include the word 
"requirement" in their title. The documents produced by 
operational personnel may be called either plans (how 
operations will be conducted) or requirements documents. One 
possible view of the interaction between systems and 
operational documentation during Phase B is shown in Figure 4. 
Note that these documents are all preliminary to a Preliminary 
System Specification, which is usually included in the RFP for 
Phase C/D procurement. 
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mkthqdology for operations planning and analysis 


Engineers at NASA/MSFC are involved in three types of Phase B 
operations planning by virtue of their assigned projects, 
existing facilities, and interfaces required with the other 

NASA L:eriteiT5; 

• Mission operations plamning 

• Ground/ C3 segment operations planning 

• Payload/POCC element operations planning 

To support these planning activities, and to support the system 
design process, there are three generic types of analyses that 
may be conducted during Phase B: 

• Interface Analysis 

• Functional and Timeline Analysis 

• Operations Effectiveness Analysis 

We will briefly discuss these planning and analysis activities 
in turn, with the objective of identifying methodology that can 
be used to accomplish each. 


MISSION OPERATIONS PLANNING 

Mission ScenarlQ Development is the earliest method used by 
operations planners. Various aspects of the total mission and 
its environment are described, such as orbital destination, 
time-frame, equipment, launch and landing site, duration, 
mission constraints, estimated crew size and make-up, and so 
on. One or more mission profiles are prepared, which is a 
"plan to" mission timeline that can be used by various program 
and engineering organizations. In Phase C/D, mission profiles 
are modified into preliminary mission timelines in the form of 
STS timelines and payload timelines. 


Flight phases (ascent, orbit, deployment / retrieval ) , maneuver 
sequences (rendezvous, orbital adjustments, deorbit), and crew 
activity block designation are part of early Flight Design. 
Aspects of flight performance are estimated including 
trajectories, consumables usage, attitude and pointing,^ 
navigation, and deployment /retrieval sequences. Analysis of 
electrical, commxanications, maintenance, lighting, and 
environmental needs lead in Phase C/D to decision on whether to 
include various flight kits. 


The use of Lessons Learned is important in mission planning. 

For example, a Spacelab 3 Lessons Learned was published in 
September 1985 and will be used to plan subsequent Sp^elab 
mission and support activities. Finally, the use of ghec^i^ts 
is a common practice in the early mission planning. The ELI 1 
division manager has a Phase B mission operations checklist 
vhich touches in some detail upon the following 
criteria/watchsigns : 
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• End-to-End Test 

• Sensitivity to variations in natural and induced 
environments 

• Independently functioning systems /payloads 

• Interlocks to prevent equipment damage due to improper 
human procedures 

• Automatic motor cutoff whenever restrained by mechanical 
contact 

• Alignment markings for when multiple orientations exist 

• Automatic onboard checkout/diagnostics 

• Commonality 

• Minimize training 

• Maximize maintainability 

• Maximize flexibility 

• Notification of automatic switchover 

• Monitoring of system status and notification of failure 

• Minimize sensitivity to contamination 

• Notification of low levels of consumables 

• Avoid irreversible characteristics 

Note that at least half of these deal with interfaces. 

GROUND/ C 3 SEGMENT OPERATIONS PLANNING 

These activities are conducted jointly by one or more NASA 
centers, often with reviews /inputs from Phase B contractors. 

For example, on AXAF the Mission Operations Plan (MOP) evolved 
by review/ revision cycles' at MSFC, GSFC, Lockheed, and TRW. 

The Ground/C3 Segment of a NASA mlsson includes: all 

ground-based mission support facilities, computers, software 
and procedures; the organizations which uses the above 
hardware/ software to support /control the mission; and the 
ground-based and orbiting relay elements. This explains why 
the MOP is so heavily oriented toward organization structure 
and responsibility, data flow and use, and command, control, 
and communication (C3). 

Formal methods are available for developing MOPs. The first is 
Orcranlzational Design methodology which has evolved over the 
past 20 years. This methodology addresses the problem of 
specifying strategies for generating and distributing 
information within the organizatxon so as to facilitate 
effective decision making. Specific stategies for 
technically-oriented and highly complex organization such as 
those which conduct NASA missions have been developed. They 
emphasize two critical points: 

• combining bits and pieces of other organizations to meet a 
new need is no alternative to rational organizational 
design 

• organizations and their misson have a technical side and a 
human side, whether at the organization, group, or 
Individual work level. 
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It is intsresting’ realize that most technical 

organizations in the U.S. are designed by engineer or 
scientests with no training in organizational design. Also, 
most technical systems are designed with operations and human 
criteria having limited impact on early decisions. 

A second method for MOP development is the Structure d Software 
Specification methodology of Yourdon, specifically data flow 
diagrams (Figure 5), data dictionaries, structured Hnglish, and 
decision tadiles. Recent advances have been made in structured 
methods for specifying real-time systems such as NASA uses 
during missions (see Mellor and Ward). 

Finally, techniques of C3 Design may be appliceLble to the 
planning of NASA missions, especially those with much 
automation. C3, of course, is part of every system regardless 
of size, providing a means of direction, coordination, and 
tasking. NASA missions involve highly complex forms of C3 
because segments and elements are located throughout the world, 
because of time-critical activities on-orbit, and because of 
the overall emphasis on safety on manned missions or while 
manned spacecraft are nearby. C3 network engineers should 
model the mission and calculate high-level effectiveness 
measures such as network reliabilities, data rates, bit error 
rates, data queue lengths at nodes, etc. 

Mission operations are the set of mission functions allocated 
to humans. These operations are allocated either to the 
ground or flight segment, and through timeline and task 
anaylses result in performancs specification for the C3 
elements, which include the Payload Operations Control Center 
(POCC). Other elements are typically a communication element, 
a processing element, and a dissemenation/archiving element. 
Analytical techniques to support C3 operations planning 
include: 

• Functional analysis— leveled flows of activity 

• Functional allocation of timing, performance, and error 
budgets 

• Interface Analysis 
PAYLOAD/PQCC OPERATIONS PLANNING 

This planning is in anticipation of payload crew operations, 
POCC operations, and payload data management. For manned 
missions , payload crew operations which must be planned are 
flight specific procedures, mission dependent training, flight 
data file preparation, and conduct of on-orbit mission 
activities. This planning during Phase B is quite limited 
developing crew functional flows, preliminary timelines fo*^ 
entire experiments, and crew schedule only to enough detail to 
estimate payload crew size. Preliminary estimates of training 
requirements, including new facilities, may be developed during 
Phase B. 
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Pof \jninsnnsd. twi s s i on , ths Pa.ylo3.cl/P0CC opsrations planning 
during Phase B is much more critical. The elimination of the 
human and the dependency on automation reduces flexibility, 
while increasing safety. Reliability generally increases with 
automation because of repeatability and redundancy which is 
^ Ground” cont rol led or automatic operations and 

data analysis now occupy a central role in the mission, 'n^e 
effectiveness of the entire mission is (for unmanned missions) 
deeply rooted in the decisions made during phase B. Often 
these decisions are management and organizational in nature, 
and must be wisely made to assure success mission operations, 
mission data capture and processing, and science data 
distribution and archiving. Planning for the ultimate 
scientific use of the mission data is much more significant 
than for manned missions with attached payloads. The ^ da t a 
manacrement function (acguisition, analysis, distribution, and 
archiving of data) replaces the safety of payload operations as 
the primary mission planning concern. 

POCC operations planning (manned or unmanned mission) during 
any Phase B involves definition and preliminary resource 
scheduling/ estimating. POCC tasks for the mission must be 
defined. Organization and operations/data interfaces are 
defined. Organization structure is defined only to a level to 
permit sizing the facility and the quantity and job categories 
of personnel. These preliminary POCC documents support NASA 
budget requests and also are supplied to contractors as part of 
the mission operations data. 

INTERFACE. FUNCTIONAL. AND TIMELINE ANALYSIS 

Interfaces arise in all design activities as top-down design 
hierarchies subdivide the system into subsystems, assemblies, 
subassemblies, etc. and as top-down functional allocations 
subdivide human activities into smaller and smaller packages 
to the job, task, and step level. The interfaces most 
appropriate for Phase B operations personnel to analysze are of 

these types: 

• organizational 

• data/functional 

• man-machine 

Analysis of organizational interfaces is critical to NASA 
mission planning when one considers the complexity of these 
interfaces: 

• NASA/Systems Integration Contractor 

• Contractor /Subcontractor / Suppliers 

• Intra-NASA 

- Program/Project 

- Center#l/Center#2 
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A useful tool for organizational interface analysis is the n2 
Giart , orginated at Bell Labs and developed by R. Lano at TRW. 
The N2 chart concept is illustrated in Figure 6 for a NOAA 
Ocean Surveillance Satellite (OSS). The organizational 
elements are displayed on the diagonal of an N3?N matrix, with 
the (I, J) position occupied by inf or mat ion /commands element J 
receives /requires from element I. As can be seen in Figure 7, 
control loops, critical functions, complex interactions, etc. 
can then be discerned. Such a chart developed from the AXAF 
MOP shows the critical function played by the Science 
Operations Center (SOC), with its interfaces to both the POCC, 
the scientific users, and the NSSDC. 

Interface definition is a critical part of the C3 design 
process. At the top level, interfaces can be defined 
generically (telemetry, schedule request, engineering data, 
etc.). Detailed quantification (data rates, quantities, 
formats, etc.) is required as design proceeds in order to 
establish throughput and computational performance 
requirements. Information interfaces can initially be defined 
by N2 charts, later in interface requirements documents, and 
finally in interface control documents (ICDs). Functional 
interfaces are documented in requirements specification 
documents as they are identified in the system design process. 
As the total system is decomposed into functional areas, 
interfaces between areas appear. These may be physical, 
operational, or both (man-machine) but are usually 
characterized by transfer of energy or data, or by procedures 
with data requirements. 

We have already mentioned data flow diagrams for defining data, 
interfaces between elements or processors. A related method 
used to define and analyze man-machine interfaces are 
Functional Flow Diagrams (Figure 8) , which are function- 
oriented as opposed to hardware-oriented. They provide a 
time-sequenced understanding of the total operation of a system 
or payload, serve as a basis for development of operational and 
contingency procedures, and pinpoint areas where changes in 
operational procedures could simplify the overall system 
operation. Timeline Analysis (Figure 9), is a companion 
methods to functional flow diagrams, which only show sequencing 
of tasks and not timing. Task Analysis takes a composite or 
related activities (a task) and breaks it into discrete actions 
of liminted nature (sxib- tasks), and and these into task 
elements (actuate a control switch, read a dial, interpret a 
signal, etc. ) . 

Finally, man-machine interfaces may be analyzed by Physical 
Models , often only soft mockups (or perhaps plywood) during 
Phase B. These are used to: 

• identify operational contraints 

• verify predicted capcdiilities, such as response times 

• locate controls, harnesses, access holes, foot holds, etc. 

• establish maintainability characteristics 

• safety analysis 


VII-16 



6. S/C Uft DATA 

7. S/C CMD, TORS TASKING 

8. TDRSS STATUS 

9. S/C TLH. TRACKING 

10. TDRSS CMD, TASKING 
n. S/C CMD, TASKING 

12. S/C CMD, TASKING 

13. DATA PROCESSING TASKING 

14. DATA PROCESSING FACILITY STATUS 


OF POG« QiJALi 



'5 




FIGURE 6 CHART FOR OCEAN SURVEILLANCE SATELLITE (OSS) 



FIGURE 7 N^ CHART KEY FEATURES 


VII-17 






ORIQItlAL PAGS IS 
OF POOR QUAUtV 


TMtt tIVIi ACOUM PAViOAO DATA 


««AT KM fCXT TAAaT 



FIPURE 8 EXAMPLE FUNCTION FLOW DIAGRAM 


I 



*•0. -«o -30 0 ♦ao ♦•© 

FIGURE 9 timeline FOR ABOVE FUNCTIONS 




yii-18 











OPERATIONS EFFECTIVENESS ANIAYSIS 

During conceptual and prelininary design, there is a natural 
tendency to permit design decisions to be driven by either 
performance, or acquisition cost. To counter this tendency, 
operations and support considerations must be consciously and 
constantly emphasized that a balanced design approach will 
emerge. How to ach i eve this emphasis is a real 
NASA/MSFC . given the specialization of engineering 
the general unavailability of engineers to work on Phase B Task 
Teams, and lack of a strong heritage of operations 
effectiveness analysis at this center. 

A measure of effectiveness is a math variable that measure how 
well a system performs (will perform) its intended function in 
a given operational environment. Operational effectiveness is 
the probability that a system can successfully meet an 
operational demand within a given time when operating \^der 
specified conditions. Operations effect ivenes s analysi s is the 
use of math models to predict operational effectiveness in 
advance of actual operations and often prior to operational 
test / simulations . 

In phase B, reliability and maintainability (R&M) are the 
earliest measures for which estimates are needed, because: 

1. Reliability of hardware in closely linked with ultimate 
mission success. 

2. R&M are drivers in design decisions. 

3. R&M are O&S cost drivers, and O&S costs are typically from 
1/3 to 2/3 life-cycle cost. 

Three svstem-level models w h ich are critical for Phase __S 
s tudies at MSEC are: (1) a system reliability model? (2) a 

system maintenance model? and (3) an O&S cost model. Human 
factors models to predict manability/habitability measures are 
important for manned payloads. For unmanned payloads that will 
be serviced on-orbit, human factors criteria are accessability , 
repairability, safety, and contamination control. 

Manuf acturing, while not part of operations^ is of Phase 

C/D and must be planned for in Phase B. Unless criteria 
as producibility and inspectability are considered by Phase B 
engineers, cost and schedule overrxons and quality control 
problems are created. 

Above all, it is emphasized that engineering specialties and 
their associated effectiveness criteria/models must be 
integrated into the Phase B task team activities. They may be 
considered part of systems engineering or given co-equal status 
to systems Ingineering and called product support or opera^ons 
effectiveness, reporting directly to the chief 
role is to define requirements in their area, conduct analyses 
in support of design, and participate in design reviews. 
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NASA SUPPORT DOCUMENTS FOR OPERATIONS PLANNING AND ANALYSIS 

The following documents are available in EL12 Branch to support 
Phase B operations planning and analysis activities: 

JA-063 Payload Mission Operations Plan (Generic) 

JA-447 Mission Requirements on Facilities, Instruments, and 
Experiments 

JA-053A POCC Telemetry Standards 

JA-455 Integrated Payload Training Plan 

JSC-14433 POCC Capabilities Document (2 Volumes) 

JSC-07700 Space Shuttle System Payload Accommodation 
(VoliJtme XIV) 

NHB Safety Policy and Requirements for Payloads Using 

1700. 7A the Space Transportation System 

MSFC Plan HOSC Functional Requirements and Implementation 
904 Plan 

Unnumbered Space Transportation System User Handbook 

JSC STS Flight Operations Baseline Operations Plan 

JSC-13000 STS Flight Assignment Baseline 

JSC-11123 Payload Safety Guidelines Handbook 

JSC-13830 NHB 1700.7 Supplement. Implementation Procedures 
for STS Payloads Safety Requirements 

JSC-10615 Shuttle EVA Description and Design Criteria 

JSC-14046 Payload Interface Verification Requirements 

ESA SLP/ Spacelab Payload Accommodation Handbook 
2104 

GSFC STD TDRSS User Guide 

101.2 

JSC-11804 Payload Operations Control Center for Attached 
Payloads 

GSFC Payload Operations Control Center for Earth-Orbiting 

Automated Payloads 
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CONCLUSIONS AND RECOMMENDATIONS 


Phase B studies are conducted from five to ten years prior to 
operations, making operations planning and analysis a difficult 
activity with many unknowns and little data. Hence it is 
natural that NASA/MSFC relies on experienced operational 
personnel and their supervisors to provide operational 
inputs/evaluations during Phase B. The process used is a 
write/review/rewrite cycle within NASA/MSFC and among NASA 
centers, using checklists, knowledge of existing facilities and 
capabilities, and experience on previous programs. Few data 
bases and quantitative methods are presently available to 
working-level NASA operations analysts to conduct Phase B 
operations planning and analysis activities. 


Operations and servicing concept definitions, and 
inputs /evaluations by operations/maintenance specialists are 
considered part-time supporting roles to the Phase B task team, 
where the emphasis seems to be on systems engineering and 
configuration definition. Technical feasibility is often in 
question on NASA future missions; this justifies to some extent 
the preoccupation with sizing, performance, and 
technology-related issues in Phase B. Operational assumptions, 
groundrules, and guidance may evolve in conjunction with these 
systems studies with unfortunately little or no supporting 
analysis, especially with regard to cost and effectiveness of 
alternatives (be they alternative requirements levels or design 
options). Contractors do appear to be devoting adequate 
attention to operations and operations effectiveness criteria. 
However, NASA is not doing in-house studies to cross-check and 
verify contractor decisions — EIL12 currently does not have the 
data bases, methodology, or personnel assigned to perform such 
analyses. Cross-checks are therefore conducted via 
telephoned/written clarification from the contractor. Some 
EL12 personnel likely have the potential to be outstanding 
effectiveness analysts for conceptual design, if they are given 
this career option. 


Recommendations are to: 


1) Develop operations analysis data bases, methods, and 
specialists to adequately staff each Phase B task team. 

2) Give operations and maintenance personnel an equal level of 
authority with systems engineering on these teams. 

3) Conduct formal operational studies prior to Phase B; or, 
require contractor to conduct them early in Phase B in 
order to define operational and maintenance concepts prior 
to system configuration studies. 

4) Assure operational effectiveness criteria and personnel are 
integrated into each Phase B task team, especially as the 
affect design decision. 
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5) Upon receipt of contractor Phase B reports, utilize 

in-house methods to cross-check/validate contractor claims 
and estimates. 

Organizational changes which may be necessary to implement the 
above recommendations are given in increasing level of change: 

1) Require more emphasis on operations in Phase B either by 
emphasizing stronger integration of systems engineering and 
EL12, or by making operations /maintenance a co-equal level 
with systems engineering on all task teams. 

2) Hire operations effectiveness engineers into EL12 and give 
them the charter /resources to develop computer-assisted 
methods to support Phase B Teams. 

3) Create an operations effectiveness group withih EL12. 

4) Create a mission logistics group in ELll or EGOl to 
perform: 

a. maintaineUoility analysis 

b. spares policy studies 

c. logistics support analysis 
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